Addons parsing improvement (dont merge yet) #578
Conversation
…e abstract, and overriding these in derived classes
…e different elemetns an added addon. Classes extending baseProject should not call addAddon or override it, instead should override these added functions
… macos instead of osx
|
@roymacdonald has this been tested more since the PR? For testing Frameworks: For testing dylibs: I'd love to merge this but would be good to know how much it's been tested across platforms ( as there are so many changes it's hard to review ). |
… override declared
…ojectGenerator into addonsParsingImprovement
…of redundant code. Preprocessor flags added properly.
… windows. This fixes openInIde button not working on windows
|
@roymacdonald let me know when its good to merge this. Do you know if this also addresses the issue of make not working on macOS / osx? ( see openframeworks/openFrameworks#8155 ) |
|
Hi @ofTheo, I have been using it a lot both on windows and macos and works fine for a lot of the things that had issues, but not linking addons dylibs correctly. I am working on it now. |
|
Thanks @roymacdonald ! |
|
Indeed it is a mess. In terms of PG, the macos/osx folder renaming is handled for most cases, but still it makes a mess in the scripts and templates folders, with lost of duplicates, and unclear which one is used, etc. |
…tion to check if it is valid for arch and target
… rules to libfiles
This is what I have done so far related to this
I have encapsulated the ofAddon class so it is easier to test that it is loading/parsing properly the values for any addon.
I have dealt partially with the macos/osx issue. I say partially because I have not tested it thoroughly and it mostly feels like a hack. But so far it works for me, I am able to use addons, local addons, addons that use libraries, xcframeworks. Still neet to test for those using frameworks, system frameworks and dylibs. Currently only testing on macos 14 (sonoma) and xcode 15.
I will setup my windows/linux computer to be able to test on those other environments as well.
The main idea behind all of it is that an addon is an addon regardless of where it sits in the filesystem. Since all the routes are relative it should not matter where these sit, thus the local addons are treated in the exact same way as the non local ones.
Then the baseProject class does not do much with these besides loading and then it is the job of each baseProject-derived-class to override the necessary functions so it adds the addons properly.
There is a lot to be cleaned and reduced since there is a lot of duplicated code and stuff not even used.
Eventually it should provide a much cleaner way of dealing with addons and project creating in general.